package 微服务.微服务技术栈介绍;

/**
 * 微服务技术栈介绍
 */
public class index {
    /**
     * 提到微服务，最先想到的，就是Spring Cloud<p>
     * 微服务，其实是分布式架构的一种<p>
     * 所谓分布式架构，就是要把服务作拆分<p>
     * 拆分就会出现各种各样的问题，而Spring Cloud仅仅是解决了服务拆分时的服务治理问题<p>
     * 至于其他的分布式中更复杂的问题，Spring Cloud并没有给出解决方案<p>
     * 所以一个完整的微服务技术要包含的不仅仅是Spring Cloud<p></p>
     * <p>
     * 微服务要做的第一件事就是拆分<p>
     * 因为传统的单体架构所有的业务功能都写在一起，随着系统越来越复杂，代码也耦合得越来越多，不利于后期维护和扩展<p>
     * 所以一些大型的互联网项目就必须去作拆分<p>
     * 会<a href="">根据业务功能</a>把一个单体的项目拆分成多个独立的项目，每个项目完成一部分业务功能，将来再进行独立开发和部署<p>
     * 我们把独立的项目称为<a href="">服务</a><p>
     * 一个大型的互联网工程，往往会包含成百上千个服务，这些服务形成一个<a href="">服务集群</a><p></p>
     * <p>
     * 注册中心 ：<p>
     * 一个业务功能往往需要多个服务来完成，就比如功能调用服务A，服务A调用服务B<p>
     * 随着功能的越来越多越来越复杂，服务之间的调用关系也会变得越来越复杂<p>
     * 如此复杂的调用关系要靠人去记录和维护，显然不可行<p>
     * 所以在微服务里，一定会有一个组件：<a href="">注册中心</a><p>
     * 注册中心会记录各个服务的ip、端口以及作用等信息<p>
     * 当有一个服务需要去调用另外的服务时，就不需要自己记录对方的ip，只需要去找注册中心，从注册中心那里去<a href="">拉取</a>对应的服务信息<p></p>
     * <p>
     * 配置中心 ：<p>
     * 每个服务都有自己的配置文件，如果需要修改配置，我们需要去一个一个的修改<p>
     * 显然行不通<p>
     * 所以在微服务里，还会有一个组件：<a href="">配置中心</a><p>
     * 它可以去统一管理整个服务集群里成千上百的配置<p>
     * 以后如果有配置需要变更，就只需要找到配置中心，它会去通知相关的服务，实现<a href="">配置的热更新</a><p></p>
     * <p>
     * 服务网关 ：<p>
     * 当微服务运行起来以后，用户就可以进行访问了<p>
     * 这时候还需要一个组件：<a href="">服务网关</a><p>
     * 因为用户并不知道要访问哪个服务，并且也不是所有人都能访问到服务<p>
     * 所以服务网关就可以用户进行校验，并且将用户的请求<a href="">路由</a>到具体的服务，同时在路由中也可以做一些负载均衡<p></p>
     * <p>
     * 分布式缓存 ：<p>
     * 用户请求到服务，就可能去操作数据库集群，而就算集群再庞大，也不会超过用户的数量<p>
     * 所以数据库将来肯定无法承受住<a href="">高并发</a><p>
     * 因此我们就会加入缓存<p>
     * 缓存就是把数据库数据放到内存中，以提高效率<p>
     * 而这种缓存还不能是单体缓存，为了应对高并发，需要做成<a href="">分布式缓存</a>，也是一个集群，操作数据库的请求需要先到缓存，缓存未命中再到数据库<p></p>
     * <p>
     * 分布式搜索 ：<p>
     * 以后用户肯定会进行一些查询操作，对于数据量不多的情况，我们可以通过缓存实现效率的提高<p>
     * 而对于<a href="">海量</a>数据的查询搜索，缓存就无能为力了<p>
     * 这时候就需要微服务中的另一个组件：<a href="">分布式搜索</a><p>
     * 数据库将来只做一些写操作、一些事务操作以及对安全性要求较高的数据存储<p></p>
     * <p>
     * 消息队列 ：<p>
     * 最后在微服务里面，还需要一种<a href="">异步通信</a>的<a href="">消息队列</a>组件<p>
     * 因为对于分布式或者说微服务来说，一个业务功能需要有多个服务参与执行时，整个服务的<a href="">链路</a>就会比较长<p>
     * 这样一来，执行时间就会等于每个服务的执行时间之和<p>
     * 所以性能是有一定的下降的<p>
     * 而通过消息队列，服务之间就不是通过调用的方式执行，而是通过消息去<a href="">通知</a>执行<p>
     * 在通知之后，原来的服务继续执行，被通知的服务也开始执行，这样就缩短了整个服务的链路，缩短了响应时间<p>
     * 所以<a href="">异步通信</a>就可以大大提高服务的并发，在一些如“秒杀”的高并发场景下就可以去利用了<p></p>
     * <p>
     * 分布式日志服务和系统监控 链路追踪 ：<p>
     * 如此庞大的一个服务集群，如果出现了什么问题，其实是不好排查的<p>
     * 所以我们还会引入微服务中的两个组件，来解决服务的<a href="">异常定位</a><p>
     * 一个是<a href="">分布式日志服务</a>，它可以去统计整个服务集群中成千上百的服务的日志<p>
     * 并统一地进行统计、存储、分析，将来出现什么问题，就比较容易定位了<p>
     * 还有另一个组件：<a href="">系统监控 链路追踪</a><p>
     * 它可以去监控运行过程中服务集群里每一个服务节点的<a href="">运行状态</a>，如CPU负载、内存的占用等<p>
     * 一旦出现问题，就能够定位到具体的某一个<a href="">方法的栈信息（存疑，没听清）</a><p></p>
     * <p>
     * 持续集成 ：<p>
     * 对于如此庞大的服务集群，部署成了一个问题<p>
     * 如果还靠人工去部署就不现实<p>
     * 我们就会通过<a href="">Jenkins</a>这样的工具去完成自动化部署<p>
     * 它可以帮助我们对微服务项目进行自动化的编译<p>
     * 再基于<a href="">docker</a>进行打包，形成<a href="">镜像</a><p>
     * 再基于<a href="">kubernetes</a>或者<a href="">rancher</a>这样的技术来实现部署<p>
     * 而这一套我们就称为持续集成<p></p><p></p>
     * <p>
     * 结合以上微服务的技术，再加上持续集成，这才是完整的<a href="">微服务技术栈</a><p>
     *
     * @param args
     */
    public static void main(String[] args) {

    }
}
